Sept. 9th Sea date: RC15 with auv-linux
- RC15 with auv-linux, 2 CPU's. No change to TREX. Front Following
- PSIM (nightly PSIM + monte carlo), FSIM (flight code test 150x speed), LSIM (cycle accurate simulator, analogous to QSIM), VSIM (with Linux), HITL (with Linux)
- PSIM with latency modelling [Brent]
- LSIM - 'angus'. Substantial task to get test platform setup. [Thom]. by Aug. 7
- Bit copy from DMO auv-linux hard drive
- QSIM needed for validation of TREX (LSIM should then work no problem).
- VSIM with linux harddisk (at least twice, preferrably 5 times)
- Task: examine *.cfg files used with QNX and insure they are the same when used with AUV-Linux
- AUV-Linux 'check-in', are we testing with what is used by DMO. Hans indicated he would use the head of CVS.
- [P1, file bugs against auv-linux for changes needed for Sept sea date to insure publishing log files (McCann) is working).
Oct. 1st Sea date:
- the head of TREX, code freeze by August 21st.
- Changes:
- Merged updates from RC15 into the head.
- Volume Survey (TBD, per John Ryan or Bob V.).
- Improved Gulper resource management (major enhancement, Angel)
- Redistributed / new partition of the model. Adding robustness to the model with more flexible constraints.
- Work will need to be done for front following (angle has already updated volume survey).
- Transect prediction enhancement (looks further into the volume survey to calculate the min/max transects which are dynamically update)
Date Unknown: Smart Gulper - goal would be November timeframe [Brent]
- Using TREX to manage Gulper sampling during a classical scripted survey
- Transition to use Corba to collect sensor data to determine Gulper firing (retiring VCS server). First step towards testing the Corba transition.
- Could be a singe CPU deployment (two user processes)
- Customer: Bob Vrijenhoek, Julio Harvey
2 days contingency sea time
Priority: P1="must have", P2="should have", P3="nice to have"
Core T-REX issues:
1. Merge front branch with mainline in SVN. [P1 - 2009]
- The current state of T-REX is divided between the HEAD and the Front branches. There are aspects of the HEAD particularly Angel's 5 reactor configuration which should be folded in. Ideally we should merge the Front branch into the mainline and declare the Front branch dead.
- Updates have been made to pull Front branch (RC15) to the head [P1, Frederic, Done Jul 16]
- Test and Validation of the SVN head [Frederic, Angel, in progress Jul 20, goal is to complete Jul 25]
2. Move to Google/T-REX [P2] - (not crucial for MBARI, but should be done to insure clean tech transfer and efficient evolution in the future)
- move our code to Google [P2 - 2010]
- clean up interface w/ EUROPA esp. for ESA project [P2, Frederic, goal mid-Sept 2009]
- Subtask: bring in latest EUROPA code to test the interface [P2, Frederic 2009 ]
- this is something long overdue and we need to work on primarily to ensure some bugs found in T-REX core and some key issues in EUROPA are incorporated. Plus not doing so incrementally and ever so often will lead to different trajectories of code base which might kill us later on. Specifically for the ESA project the last item needs to be undertaken anyway since APSI will need to replace EUROPA.
3. Improvements to PSim for AUV dynamics model (partially checked in to Front branch 2009)
- this is to make the PSim reflect the uncertainty of the environment as well as to do a better job reflecting the dynamics of the AUV itself. This also ties in with the comment from Brent to patch the PSim to reflect the latency of execution of commands sent to the VCS. This should be managed by Brent or Thom as it is a relatively independent model and will still be a strong basis for testing purposes for further development of TREX. [P1, Brent, Frederic to meet with Brent on Wednesday, needed by mid-August in order to be used by Sept. sea date]
4. Cleaner separation of model (e.g rules.nddl) [P3, time should be allocated in the schedule to allow refactoring, test plan is to use .valid files to verify model correctness. Goal would be to test at sea October 2009 or later]
- this involves (along with #5 below) of cleanly separating the model elements needed for a specific mission and structuring the code base in a way that is more intuitive instead of lumping all the constraints in one file.
5. Better configuration mgmt. of files in T-REX [P3 - plan for December or 1Q2010, since build process changes are disruptive]
- related to above, but more focused on the directory structure and build process of T-REX and moving away from the ctd2007 based directory structure.
6. Send more data from VCS to T-REX [P1 - plan for October 2009, low risk modification]
- by putting the lat/long into state publisher which in turn gets put in vehicle state timeline, we will be able to use the log files directly for Google Earth visualization without doing convulsions as Alhayat needs to do now.
7. Modeling how to break up a survey or goal and continue/need for interruption [Potentially high risk modification, will require re-engineering of top level models and potential modification of TREX. Volume survey presents an easier 'restart' manually, side note from Frederic: Volume survey demonstrates the capability of TREX more than front following.). Plan for November/December, will likely 3 or months of effort (simulator and sea dates). We may not want to do this in 2009 (plan for 2010)
- this is an important (hence in bold font) issue that needs to be tackled and also something we signed up to do this year. Namely to be able to interrupt a mission and then resume. It will show a clear demarcation with the existing Layered Control work and really demonstrate that we can use plan projection for tasks which are less reactive and interrupt driven. It primarily involves modeling and will require you to be involved. It might be a case study for more complex modeling where Brent/Thom can look over your shoulder. We should aim to do this task as soon as possible given its utility (including what Julio seems to have mentioned on Monday) and its demonstration of clear implication of our work, not to mention publication possibilities.
Angel:
8. Implementation of parametric functions for Gulper usage [P1 for Oct. 1]
- this is the effort Angel is focusing on now and will provide utility-estimate based means to figure out when to trigger gulpers. More importantly this could be used in conjunction with T-REX Jr. where no deliberation for nav/control will be necessary and the standard script based approach in concert with cluster based estimation and these functions drive how a light-weight version of T-REX can be used. I have made this in bold font also given it should be considered on the critical path.
9. Resource reasoning (i.e how many gulpers left for the remainder of the mission) with and without task interruption. [P2 since there are risk associated with the associated model changes, AND, Angel is gone end of Aug. not recommended for 2009]
- this task is tied in with #7 above as one starting point for resource reasoning albeit of a simpler variety. The objective would be to see if goals can be executed/dropped in the light of existing gulper availability at sea and to do simple resource reasoning. In the event that when our AUVs have 48 hour battery charge and can revisit the location in the bay after an initial survey, the need to do this simple kind of reasoning increases.
T-REX items for Brent/Thom for '09
10. Psim modeling latency [P1 Brent for Sept deployment, target is 2nd week in Aug]
- this issue is directly related to #3 above. And would be a nice clean sub-task that Brent can work on.
11. VCS Config file (e.g ctd1 in devices. cfg) [P3, this task may be elimated if we transition to Corba]
- this should be wrapped up with #5 above to get an overall clean approach to dealing with varying configurations. Not only should the T-REX core be properly and systematically reconfigured, but so should the VCSServer. I suggest all file configuration issues (this and #5) be given to Thom.
12. Garbage collection of behaviors on stack (Tom O.) [P3, Improves FSIM efficiency, November ?]
- For longer missions, the stack size may be an issue (setpoint 0 inserted as IDLE instruction). Another option is to add an idle behaviour with a timeout and idle_stop behaviour to terminate idle.
- an item for Brent and Thom to work on. More specifically this might be something Thom can use to dive into AUV code given he's not at all familiar with how it is sturcutred other than having skimmed it some time ago.
13. Failure tracking during development and deployment [P1]
- this item relates to code checked in partially by Conor which might need modification and used for development time tracking and fixing of bugs. It also relates to issues in identifying a cause of failure and to see how improvements/augmentation can be done.
- Explaination: there is some instrumenting in TREX that facilitates debug, new developers need guidance on how to utilize the instrumentation output to understand what to fix/change. [P1]
- Additional instrumentation or improvement to existing instrumentation [P3]
- Pre-deployment review with DMO of operation parameters (max speed, max depth, check-in frequency, localization (too close to shore)). Cruise plan with details (sensors, operational parms) [P1]
- Deployment results analysis for concise root cause on failures - deployment results report [P1]
14. Set up a notification mechanism of which behavior is currently running on the stack (Tom) [P3, November-December]
- this is important so in the future T-REX can work around anomalies when lower level behaviors are superseded and T-REX needs to be contexually aware of vehicle state.
15. For a light weight VCS server (T-REX Jr) see attachment to this email [P2 - date is TBD]
- a. fire gulper without Layered Control
- b. VCSServer has no expectation on T-REX activity (i.e there is no need to track pings anymore) and it is robust to the case where T-REX is dead; this property should also be checked and applied to the StatePublisher
- c. VCSServer does not launch the Supervisor but is instead launched by it and reflects the nominal operation of the vehicle (ie what Hans does)
- this is an important (therefore in bold) part of our development to demonstrate this year and will make us more ubiquitous and possibly something Hans can use on his own provided for feature tracking the features are already encoded in the clusters that have been created.
16. Track multiple sensor signals for firing gulpers [P2, follow-on to TREX-jr / SmartGulper, likely 2010]
(important and useful for T-REX Jr). Share task with Angel.
- we will definitely need this in the near term (therefore also in bold). However the way in which we need to put this development feature together is in a way that differentiates us from what Rob and Layered Control can do.
17. Connecting a synthetic ocean model to the Linux Sim [P2, Goal is November but could be 2010, Tom O.]
- current Sim (both QNX and its Linux port) are limited in not being able to model dynamic features in the ocean. Since T-REX is going after unstructured phenomenon in the ocean, we need a way to be able to model them on shore to test the system more robustly. Mike Godin has some kind of a connection with a ROMS model. We should connect with him to understand what has been done to date.
Sea dates mission targets:
18. We agreed that for the week of Sept 7th when AUV-Linux will be tested and if/when we get a chance to do a full days mission we will use RC15 (i.e RC14 with the temporal constraint fix from the July 1st mission). We do not want to have any other changes brought in even if this is a test of Linux and not T-REX.
19. For the Oct 1st mission we should target (subject to agreement with John) an INL survey but use the updated 5 reactor configuration from Angel.
20. I was under the impression from an earlier schedule from John that Oct 26th is an autonomy day. But Rev 8 of the Zephyr schedule does not show that. This needs to be worked out with Teresa/Chris Grech in addition to the two floater days we still have.
Plan visualization: (Alhayat)
Both the items are things we should get Alhayat to develop during his stay, and one which seems doable. However his approach thus far is not wholly satisfactory and we need a way to have interpolation of sensor data clearly visible within Google Earth or COVE. So this should be carefully supervised.
- Contact Google Earth team about missing features.
21. Visualize plans with track: show high-level tokens on the track with Google Earth (check on status of COVE and keep that engagement going)
- do with using KML files first. [P1 - Done, Alhayat]
22. Make the visualization dynamic so real-time evolution can be shown in GE (programmatic interface) (P2 - goal mid-Aug, Alhayat)
- Recommendation is javascript and GE as this seems far more stable and has a larger user base even for ocean based visualization.
